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Summary 

A major goal of the Digital Systems Technology Branch at 
the NASA Lewis Research Center is to identify and develop 
critical digital components and technologies that either 
enable new commercial missions or significantly enhance the 
performance, cost efficiency, and/or reliability of existing and 
planned space communications systems. NASA envisions a 
need for low-data-rate, interactive, direct-to-the-user commu- 
nications services for data, voice, facsimile, and video con- 
ferencing. The network would provide enhanced very-small- 
aperture terminal (VSAT) communications services and be 
capable of handling data rates of 64 kbps through 
2.048 Mbps in 64-kbps increments. Efforts have concentrated 
heavily on the space segment; however, the ground segment 
has been considered concurrently to ensure cost efficiency 
and realistic operational constraints. The focus of current 
space segment developments is a flexible, high-throughput, 
fault-tolerant onboard information-switching processor (ISP) 
for a geostationary satellite communications network. The 
Digital Systems Technology Branch is investigating both cir- 
cuit and packet architectures for the ISP. This report concen- 
trates on destination-directed, packet-switched architectures 
for geostationary communications satellites. 


Introduction 

In the mid 1980’s NASA began the Advanced Communi- 
cations Technology Satellite (ACTS) Program to develop a 
30/20-GHz geostationary communications satellite to be 
launched in 1993. This satellite will open up the Ka-band fre- 
quency for commercial communications and demonstrate 
multibeam and hopping-beam antennas and onboard process- 
ing technology. The ACTS system utilizes time-division mul- 
tiple access (TDMA) uplinks and time-division-multiplexed 
(TDM) downlinks. One drawback of TDMA uplinks is that 
the Earth terminals are forced to transmit at a much higher 
data rate than their actual throughput rate. For example, in 
the ACTS system an Earth terminal wishing to transmit a 
single voice channel at 64 kbps would have to transmit at a 
burst rate of 27.5, 110, or 220 Mbps. This, in effect, drives 
the cost of the Earth terminals up dramatically by requiring 
either substantially higher power transmitters or larger anten- 


nas, both of which are major cost drivers in a low-cost Earth 
terminal. Therefore, recent emphasis has been placed on 
reducing the cost of the Earth terminals. One way to accom- 
plish this is to eliminate the need for high-power transmitters 
on the ground by allowing the user to transmit at a lower data 
rate by using one of the following uplink access techniques: 
frequency-division multiple access (FDMA), hybrid multi- 
frequency-time-division multiple access (MF-TDMA), 
or hybrid multifrequency-code-division multiple access 
(MF-CDMA). TDM has been chosen for the downlink trans- 
mission technique because the high-power amplifier onboard 
the satellite can then be operated at maximum power, thereby 
increasing the downlink signal strength and enabling the use 
of very-small-aperture terminals, or VSAT’s (ref. 1). 

NASA envisions that mesh VSAT satellite communica- 
tions systems will be needed for direct distribution of data to 
experimenters and direct control of space experiments. In the 
commercial arena NASA envisions a need for low-data-rate, 
direct-to-the-user communications services for interactive 
data, voice, facsimile, and video conferencing. Such a system 
would enhance current communications services and enable 
new services. For this type of satellite system to exist, it must 
be cost competitive with terrestrial systems at the user level 
while enhancing the existing quality of service. The key to 
making this system cost competitive is to drive the cost of the 
Earth terminals down and spread the cost of the satellite 
among tens of thousands of users. NASA has completed and 
is continuing to perform a number of studies on such commu- 
nications systems (refs. 2 to 7). 

Mesh VSAT satellite networks can be implemented by 
using either a circuit-switched architecture, a packet-switched 
architecture, or a combination of the two. Intuitively, it 
appears that a circuit-switched network would be far simpler 
to implement; however, a packet switch has many potential 
advantages over circuit switching. The Digital Systems Tech- 
nology Branch at NASA Lewis has investigated both circuit- 
and packet-switched architectures for FDM A/TDM satellite 
networks (refs. 8 and 9). Many problems have been identified 
with the front-end onboard processing requirements, satellite 
hardware complexity, and inefficient utilization of the uplink 
spectrum for FDMA uplinks. Therefore, NASA Lewis has 
redirected its efforts to investigating mesh VSAT networks 
utilizing MF-TDMA uplink access techniques in order to 
alleviate some of the problems associated with FDMA, This 
report summarizes the initial findings of those efforts. 



The report describes the overall network requirements, the 
network architecture, the multicasting requirements, the pro- 
tocols and congestion control, and the individual subsystems 
of a destination-directed, packet-switched (DDPS) MF-TDMA/ 
TDM geostationary satellite network for commercial commu- 
nications. 


Network Requirements 

In order to begin designing the conceptual satellite archi- 
tecture, a list of salient requirements has to be created: First, 
the system must be economically viable and cost competitive 
with existing terrestrial telecommunications systems while 
enhancing existing services and adding new ones. Second, 
the system must provide voice, data, facsimile, datagram, 
teleconferencing, and video communications services. In 
order to provide these services, the Earth terminals will trans- 
mit fixed-length packets in increments of 64 kbps through 
2.048 Mbps. All terrestrial data entering an Earth terminal 
will be packetized in order to simplify the onboard process- 
ing hardware. Third, the system must be capable of point-to- 
point, multicast, and broadcast transmission. Multicast 
capability is necessary for teleconferencing and video 
conferencing services. Broadcast transmission may be neces- 
sary for network control. Fourth, the satellite has to accom- 
modate destination-directed packets on a packet-by-packet 
basis. Fifth, the satellite network must be designed so that 
contention and congestion are handled in the Earth terminals 
and packets are not dropped at the satellite. Because of the 
long round-trip delay times to geostationary satellites (on the 
order of 250 msec) if packets are dropped, the window for 
requesting a retransmission and the data buffering involved 
are unacceptable. 


Description of Network Architecture 

The baseline network consists of as many as four satellites. 
Only one satellite is required for an operational system. How- 
ever, a minimum of two satellites is required to market the 
system — one acting as a spare. Without two satellites it is 
extremely unlikely that any service supplier would subscribe. 
Two additional satellites are considered in the network design 
to accommodate transoceanic communications. Also, it is 
necessary to consider a four-satellite system in order to fully 
understand the multicasting and broadcasting requirements 
and limitations. In order to determine the Earth terminal size, 
the numbers of beams, etc., operation is assumed to be 
30 GHz up and 20 GHz down, although all switching and 
processing are relatively independent of carrier frequency. 
Transmission is MF-TDMA up and TDM down. There are 
eight uplink beams with 2 14 addresses per beam and eight 
downlink hopping beams per satellite. Each downlink beam 


has eight dwell locations with 2048 addresses per dwell. 
Associated with each uplink beam is a multichannel 
demultiplexer that can demultiplex thirty-two 2.084-Mbps 
channels. Following each demultiplexer is a demodulator/ 
decoder pair and a packet buffer. Associated with each down- 
link is a burst buffer, an encoder, and a 160-Mbps burst 
modulator. The switch performs both space and time switch- 
ing. The switching, routing, and congestion control are the 
responsibility of the satellite control and monitor system 
onboard the satellite (figs. 1 and 2). 

Many of the relative numbers used to establish the network 
size and data rates are taken from architecture studies 
performed by TRW and Space Systems/Loral. These reports 
include a complete link budget and hardware analysis 
in sufficient detail to estimate size, weight, and power 
requirements. 




Figure 1. — MF-TDM A/TDM network for satellite and Earth terminals 
(refs. 10 to 12). 
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Figure 2.— Mesh VSAT processing satellite. 


Multicasting and Broadcasting 

For this DDPS satellite network the degree of multicasting 
and broadcasting must be limited or the address header will 
become unrealistically large and the packet efficiency 
(information-to-overhead ratio) unacceptable. In the extreme 
limit, for four satellites each with eight downlink beams and 
eight dwells per beam, there are 256 different dwell locations 
giving 2 256 different combinations of multicasting. A mini- 
mum of 256 bits would be required in the header just to 
specify multicasting. Obviously, this is unworkable. The 
other extreme would be to accommodate only point-to-point 
communications. In this case, only 19 bits would be required 
to specify the destination. Table I shows a variety of possible 
multicasting scenarios and the number of required mapping 
bits. Figure 3 shows the number of possible multicast loca- 
tions and figure 4 shows a possible mapping that would occur 
onboard the satellite. Notice that the hardware mapping may 
require additional bits to be added to the header for easy 
hardware implementation. 

The following observations can be made about 
multicasting: First, intradwell multicasting requires only pre- 
defined group addresses. No additional packet regeneration 
or switching and routing hardware is required because every 
location within a dwell receives all transmissions. However, 
because the users need to know which transmissions are 
intended for them, they need a list of destination addresses: 
one defining its location and an additional address to define 
multicast groups that the user belongs to. Second, in order to 


TABLE I. - BROADCAST OPTIONS 


[Assume 8 dwells/beam, 8 beams/satellite, 4 satellites, and 
2048 addresses/ dwell.] 


Multicasting description 

Number of 
multicast 
locations 

Number of 
combin- 
ations 

Minimum number 
of destination 
bits* 

Single dwell (intradwell) 

1 

1 

2+3+3+11+0=19 

Multiple dwells in a 

8 

256 

2+3+8+11+0=24 

beam (interdwell) 




Multiple beams, all 

8 

256 

2+8+3+11+1=25 

dwells (interbeam) 




Multiple satellites, all 

4 

16 

4+3+3+11+1=22 

beams and dwells 




(intersatellite) 




Interbeam and interdwell 

64 

2 M 

2+8+8+11+0=29 

Intersatellite and inter- 

32 

2 32 

4+32+3+11+1=51 

beam 




Intersatellite, interbeam. 

256 

2 256 

4+32+256+11 

and interdwell 



+0=303 

Interbeam or interdwell 

16 

512 

2+8+8+11+1=30 

Intersatellite or interbeam 

12 

272 

4+8+3+11+1=27 

Intersatellite or interdwell 

12 

272 

4+3+8+11+1=27 


•Minimum number of bits = Satellites + Beams + Dwells + Address + Multicasting. 


reduce the packet header substantially, interdwell 
multicasting will not be accommodated. This is a reasonable 
constraint particularly because it seems unlikely that a user 
would wish to multicast to more than one dwell in a single 
beam without broadcasting to all dwells within the beam. 
Third, for a four-satellite network with eight beams per satel- 
lite a total of 32 multicast locations exist. This requires 
32 bits (one per beam) to specify the multicast location. If all 
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Figure 3. — Four- satellite network (4 satellites, 32 beams, and 256 dwells). 
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Figure 4. — Shared -bus/distributive memory mapping. 

32 beams were on the same satellite, only 32 bits would be 
required. However, because routing occurs by first mapping 
to the satellite and then mapping to the beam (fig. 4), 36 bits 
are required: 4 bits to specify the satellite and 32 bits to 
specify the beam. Fourth, when multicasting is not specified 
down to the specific dwell (i.e., 256 bits for 256 dwell loca- 
tions in a four-satellite system), an additional bit is necessary 
to specify multicast versus nonmulticast transmission. With- 
out the multicasting bit one could not determine whether to 
map a message to one dwell or all dwells within a given 
beam. 


Protocols 

Initial Access and Disconnect 

Initial access into the system would be through a reserved 
signaling channel. One or two timeslots of one preselected 
channel for each multichannel demultiplexer would be 
reserved for requesting entry into the system. This channel 
would be set up in a slotted aloha format and would accept 
packets containing a request for a data transmission rate and 
the type of transmission: point to point, multicast, or broad- 
cast. Additional information that may be conveyed during 
initial access would be related to the type of data being trans- 
mitted (voice, video, facsimile, datagram, etc.) and to the 
effective data throughput rate. This information may help the 
network controller anticipate and correct for congestion prob- 
lems. Upon reception of the initial access request, the satellite 
will respond by a downlink inband orderwire message as to 
whether the request is granted or denied and give a corre- 
sponding frequency and timeslot allocation. Disconnect 


requests will be handled by inband orderwires. A disconnect 
packet will be sent to the network control. The network con- 
trol will then initiate a request-granted orderwire to the 
requesting terminal, thus freeing up the previously occupied 
channel allocation. 

Ideally, the portion of the network control that accepts and 
rejects access and disconnect requests would reside onboard 
the spacecraft in order to minimize delay. Because of the 
greater onboard complexity that this would entail and the 
direct effect that this complexity has on network reliability, 
placing this portion of the network control onboard may not 
be optimal. Further studies are needed in this area before a 
reasonable conclusion can be made. 

Packet Formats 

The Earth terminal will translate incoming data (packets, 
voice, continuous data, etc.) into fixed-length message pack- 
ets that are specific to the satellite network. This simplifies 
the onboard processing. 

The tradeoff on packet length is between improved packet 
efficiency and increased onboard storage. The longer the 
packet, the greater the packet efficiency owing to a reduction 
in the overhead-to-information ratio; however, the longer the 
packet, the greater the onboard storage requirements. The 
length of each message packet has been chosen to be 2048 
bits. In order to reduce the amount of onboard storage, each 
packet is further divided into two types of subpackets: a header 
subpacket and an information subpacket. Each subpacket will 
be 128 bits long. Each message packet consists of 16 
subpackets: 1 header subpacket and 15 information 
subpackets. An analysis of the packet structure is given in the 
appendix. 

The header subpacket consists of three fields: source 
address, destination address, and parity (table II). The source 
address consists of three subfields: source-satellite, source- 
beam, and source-user address. A source address must 
accompany each packet in a DDPS because the destination 
user has to know where each received packet originated. The 
source-satellite and source-beam subfields are not required 
during transmission to the satellite because they can be 
reconstructed onboard. Hpwever, they are required in the 
packet received at each Earth terminal. The destination 
address consists of five subfields: multicast, destination- 
satellite, destination-beam, destination-dwell, and destination-user 
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TABLE II. - HEADER SUBPACKET FIELDS 


Header address bits 

Number of bits 

Source bits: 


Four satellites 

2 

Eight beams per satellite 


16 384 addresses per beam 

9 

Total 

mm n 

Destination bits: 


Multicast 

i 

Four satellites 

4 

Eight beams times four satellites 

32 

Eight dwells per beam 

3 

2048 addresses per dwell 

11 

Total 

51 

Parity 

58 

Total address bits 

128 


Uplink frame 

Uplink _ 
subframe 


Subframe 1 


Subframe 2 


• • • • 


Subframe 1 6 







TS32| 


Figure 5. — Uplink TDMA frame. (Frame, 32 msec; subframe, 2 msec; 
time slot, 62.5 psec.) 


address. The destination address provides routing information 
to the onboard switch and is required as part of the uplink 
packet structure. The multicast, destination-satellite, destina- 
tion-beam, and destination-dwell subfields are not required as 
part of the packet received by the Earth terminal. The parity 
field uses the remaining bits and provides forward error cor- 
rection and detection. It is imperative that the header 
subpacket be received at the satellite and the Earth terminals 
correctly, or the quality of service will be unacceptable. 
Transmission errors that are detectable but not correctable 
will result in dropped packets. Transmission errors that 
exceed the decoder’s error detection capability may result in 
packets being misrouted, causing multiple problems: The 
destination user will not receive the packet, and users not 
expecting the packet will receive it. Errors occurring in the 
destination-satellite, destination-beam, or multicast fields are 
extremely severe because this condition results in multiple 
misrouted or dropped packets. Therefore, the choice of error 
correction code to be used in the header subpacket is 
extremely important. 

The information subpacket consists of two fields: an infor- 
mation field and a parity field. The information field contains 
communications data that are being passed from Earth termi- 
nal to Earth terminal. These can be continuous-transmission 
data such as voice or standard packets that have the satellite 
network packet structure overlaid. The parity field provides 
error correction that is necessary to maintain a desired quality 
of service — assumed to be approximately 10“ 7 through the 
satellite network. 

MF-TDMA Uplink Frame Structure 

Each 40-MHz uplink beam has 32 wideband channels 
separated in frequency and transmitting at 2.048 Mbps 
(uncoded transmission rate). The uplink frame is 32 msec 
long. This length allows transmission of one complete mes- 
sage packet per frame (see the appendix). Each frame is fur- 
ther divided into sixteen 2-msec subframes, and each 
subframe is further separated into thirty-two 62.5-jisec 


timeslots. Each timeslot corresponds to a 64-kbps channel 
(fig. 5). Because the MF-TDMA system requires bit 
synchrony at the satellite, there are no guardbands or pre- 
ambles in the frame structure. 

TDM Downlink Frame Structure 

Two types of downlink frame structures have been identi- 
fied for this architecture (ref. 13): the dedicated reference 
burst format and the integrated reference burst format (figs. 6 
and 7). 

For the dedicated reference burst format the reference 
bursts occur as the first eight bursts of a frame (one burst per 
dwell) and are followed by the traffic bursts. The advantage 
here is that the user always knows where the reference burst 
is relative to the beginning of the frame. This eases network 
synchronization because the reference burst locations do not 
change with changing traffic patterns. Three problems exist 
with this structure: First, some additional downlink frame 
inefficiency is associated with the added bursts when consid- 
ering preambles and guard times. However, this additional 
frame inefficiency is minimal for frame lengths of 1 msec or 
more. Second, and most important, the dwell time for the ref- 
erence burst would be extremely fast and may overstress the 
beam-forming electronics. Sending the equivalent of a one- 
packet burst at approximately 160 Mbps would require the 
beam to fully reconfigure in less than 12.5 jisec. Third, the 
reference burst message would have to be treated 
(assembled) differently than information messages because 
the reference burst would be received as one complete packet 
and the information messages would be received as a series 
of subpackets. 

For the integrated reference burst format the reference 
burst control messages would be the first message in each 
dwell. This structure is slightly more efficient than the first 
because it requires eight fewer bursts, thus eliminating pre- 
amble overhead associated with those bursts. Another advan- 
tage is that the reference burst message can be assembled on 
the ground exactly like an information message. The disad- 
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RBD Reference burst dwell 

SPD Subpacket dwell 

CBTR Carrier and bit timing recovery 
UW Unique word 

RB ID Reference burst ID (header subpacket) 
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Figure 7. — integrated reference burst. 


vantage of this method is that the reference burst location 
will change as the burst time plan is modified. 

The downlink frame format has not been chosen. For ease 
in network timing the dedicated reference burst format is bet- 
ter and would be the preferred choice. However, the inte- 
grated reference burst format has greater potential for. sim- 
plicity in satellite hardware, although a detailed hardware 
design has not been completed. The choice will be made by 
first considering satellite complexity and reliability and then 
considering the networking. 


In order to simplify network timing, the downlink frame 
time is identical to the uplink frame time of 32 msec. The 
minimum dwell size of 80 psec corresponds to a requirement 
of at least 100 packets (100 subpackets transmitted in 
16 subframes) being transmitted to any single dwell (4 per- 
cent of the total frame). An analysis of this is given in the 
appendix. 

A superframe structure will be placed over the TDM frame 
structure. Various orderwire messages will be reserved for 
particular frames within a superframe. 
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Downlink Orderwire Message Format 

Orderwires will be used to convey satellite switch status, 
system timing information, initial access granted and denied 
messages, etc. The downlink orderwire message will be ei- 
ther the First packet of each dwell for a distributive flow con- 
trol downlink frame structure or be transmitted independently 
and in its entirety for the dedicated reference burst format. 

Congestion Control 

In a DDPS satellite network congestion control is a major 
concern. Congestion occurs when more information than is 
available is destined for a specific downlink dwell. This can 
occur because the data packets are self-routing and the rout- 
ing information is not available until the packet arrives at the 
satellite. Because of the long propagation delay from the sat- 
ellite to Earth (125 msec), “handshaking” and requests for 
retransmission are impractical. In addition, the limited stor- 
age capability on the spacecraft also makes buffering of 
numerous packets for thousands of users impractical. There- 
fore, a congestion control method has to be developed that is 
specific to this DDPS satellite system. 

Numerous methods have been identified to deal with this 
problem (refs. 14 to 16). The methods consist of ground- 
based and combined ground-and-satellite -based control (dis- 
tributive flow control) algorithms. Analysis has shown that 
ground-based methods alone are unacceptable because the 
switch is underutilized owing to the conservative nature of 
these algorithms. The most promising approaches utilize glo- 
bal feedback from the satellite, indicating onset of congestion 
combined with a ground rate-based and bursty self-feedback 
control. 

For distributive flow control algorithms the onboard por- 
tion of network control continually monitors the downlink 
burst buffers to determine the current capacity of each down- 
link dwell location. The network control periodically trans- 


mits information regarding the current state of the downlink 
buffers to all Earth terminals. This information indicates the 
relative capacity of each downlink dwell. The network con- 
trol then sets a threshold for capacity. Once that threshold is 
exceeded, all Earth terminals transmitting to that dwell loca- 
tion have to reduce their effective transmission rates. It is up 
to the Earth terminals to institute the flow control. All flow 
control, acknowledgments, and buffering are performed at 
the Earth terminal. 

Determining the satellite buffer thresholds is a major area 
of study. The threshold is set by the network control in order 
to allow the Earth terminals adequate time to institute flow 
control before a congestion problem occurs in the downlink 
burst buffer. Setting the threshold too high will allow conges- 
tion to occur. A conservative threshold setting will cause 
underutilization of the satellite resources. Because the traffic 
patterns are not deterministic, neural networks are being con- 
sidered to solve this problem. 


Network Hardware 

Earth Terminals 

The Earth terminal is composed of indoor and outdoor 
units (fig. 8). The indoor unit consist of a terrestrial interface, 
a protocol converter, a packet formatter consisting of a packet 
assembler and an encoder, a message queue, a 2-Mbps 
MF-TDMA burst modulator, a 160-Mbps burst demodulator, 
a decoder, a message assembler, an orderwire processor, and 
timing and control circuitry. 

The Earth terminals will interface to the terrestrial tele- 
communications network at the data service unit zero (DSO) 
rate (64 kbps); the integrated services digital network (ISDN) 
basic service rate, 2B+D (144 kbps); Tl-type rates (1.544 or 
2.048 Mbps); and any rate from 64 kbps to 2.048 Mbps in 
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queue 


burst modulator 
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converter 
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Timing and control 


Message 

assembler 


Decoder 


160-Mbps 

burst 

demodulator 




Frequency 


conversion 
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Figure 8. — Earth terminal. 
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64-kbps increments. In addition, the Earth terminal will be 
capable of interfacing to commercial communications equip- 
ment and will be compatible with commercial standards. 

The protocol converter provides an interface between the 
commercial communications packet-switching standards and 
the internal packet-switching protocol. All handshaking, 
acknowledgments, and flow control with the terrestrial net- 
works will occur here. 

The packet formatter breaks (or appends) terrestrial pack- 
ets into satellite network packets of constant length. Each 
packet is further subdivided into information subpackets. The 
source and destination addresses are generated as a separate 
header subpacket. The header and information subpackets are 
encoded and passed on to the message queue for transmis- 
sion. 

The decoder decodes header and information subpackets. 
Because the header and information subpackets will be 
encoded with different codes, the Earth terminal decoder sub- 
system will consist of either a reconfigurable codec or two 
separate codecs. 

The modulator and demodulator are two completely sepa- 
rate units. Presently, it is envisioned that the uplink modulator 
will produce a differentially encoded quaternary phase-shift- 
keyed (QPSK) signal and will burst at approximately 
2.048 Mbps. On the downlink a burst demodulator is required. 
The data rates will be approximately 160 Mbps, and the modu- 
lation format has yet to be determined. A continuous phase- 
modulation format is desired in order to run the transmitter at 
saturation while maintaining spectral efficiency. 

The message assembler reads the demodulated data, strips 
off the source address fields, and reassembles the orderwire 
messages and any messages destined for that Earth terminal. 
The reassembled messages are then passed on to either the 
orderwire processor or the protocol converter for entry into 
the terrestrial communications network. Assuming the 
integrated reference burst format, the messages would be 
reassembled in the following manner: The first subframe 
would contain all header information. The message assem- 
bler would read each subpacket and record the timeslots 
of the subframe in which each message destined to that ter- 
minal resides. During the remaining subframes the informa- 
tion subpackets residing in the stored timeslot locations 
would be appended to the previously stored subpackets, 
requiring that all messages are routed through the satellite in 
exactly the same way for the duration of a frame. This 
requirement should not be a problem in an MF-TDMA/TDM 
architecture. 

Because this communications network utilizes time- 
division multiplexing on both the uplink and the downlink 
with downlink-bursted data transmission in the 160-Mbps re- 
gion, the timing and control of the communications channel 
are critical. The timing and control system (T&CS) is respon- 
sible for obtaining and maintaining synchronization with the 
satellite. The T&CS informs the burst demodulator of the ap- 
proximate time of burst arrival and receives a signal indicat- 


ing actual burst arrival times. The T&CS uses the information 
obtained from the demodulator to adjust the Earth terminal’s 
receiving-side timing in order to synchronize the Earth termi- 
nal to the network. The T&CS also receives network control 
information from the orderwire processor and uses this infor- 
mation to determine what type of information is entered into 
the control fields of the transmitted packets. In addition, the 
T&CS will turn off the transmitter and the modulator during 
periods when the Earth terminal has relinquished access to 
the satellite uplink channel. 

The outdoor unit contains the RF equipment consisting of 
a frequency conversion unit, a high -power transmitter (HPA), 
a diplexer, an antenna system, and a low-noise receiver 
(LNR). The HPA is required to produce approximately 2 W 
of transmitting power. The required noise figure for the LNR 
is approximately 2.6 dB. The outdoor unit accounts for most 
of the Earth terminal cost. 

Multichannel Demultiplexer/Demodulators 

The multichannel demultiplexer/demodulator (MCDD) is a 
multifrequency channelizer and shared demodulator. On- 
board demultiplexing of wideband channels is performed by 
the multichannel demultiplexer (MCD). The channelizer op- 
erates relatively independently of the modulation scheme al- 
though some optimization for the channelizer may be per- 
formed if the modulation format has been identified early on. 
The MCDD has been identified as a critical subsystem that 
needs to be developed for an MF-TDMA/TDM architecture. 
Acousto-optical, optical, and digital signal-processing tech- 
nologies have all been identified as candidates for imple- 
menting an MCD. NASA is investigating each of these 
approaches through contracts, grants, and in-house activity 
(ref. 17). 

Amerasia Technology Incorporated has completed the sec- 
ond phase of a Small Business Innovative Research contract, 
NAS3-25862, to develop a proof-of-concept (POC) MCDD 
(ref. 18). The MCD uses a convolve-multiply-convolve tech- 
nique (fig. 9) to perform the demultiplexing function and is 
implemented by using a reflective array compressor. The 
demodulator was implemented for binary phase-shift-keying 
(BPSK) modulation. 

Westinghouse Electric Corporation Communications Divi- 
sion is under contract to NASA Lewis (NAS3-25865) to 
develop a POC MCD that demonstrates the capability of 
demultiplexing 1000 Iow-data-rate FDMA uplinks (ref. 19). 
The multichannel demultiplexer is implemented as a coherent 
acousto-optic radiofrequency spectrum analyzer utilizing 
heterodyne detection with a modulated reference (fig. 10). 
Like the reflective array compressor’s (RAC) surface acous- 
tic wave implementation, the optical MCD is expected to 
have better size, weight, and power requirements than a fully 
digital MCD and does not require a high-speed analog-to- 
digital (A/D) converter at the front end. The POC model will 
have a dynamic range of approximately 80 dB and will be 
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Figure 9. — Convolve-multiply-convolve chirp transform, where S/ is 
input signal; t is time; <o s is signal frequency in radians; k is linear 
rate of change; coq, c*>i , and o> 2 are frequency in radians; B is 
bandwidth; T is time; d is delay; and Sq is output signal. 
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Figure 1 0. — Optical multichannel demultiplexer. 
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Figure 1 1 .—Digital MCDD. 


capable of demultiplexing 1000 45-kHz channels. Because most 
of the components are passive acousto-optic devices, this imple- 
mentation of the MCD is highly reliable and radiation tolerant. 

TRW is under contract with NASA Lewis (NAS3-25866) 
to develop a POC MCDD using advanced digital technolo- 
gies (ref. 20). The composite FDM signal is A/D converted 
and channelized into wideband channels of 2.048-MHz band- 
width. Each wideband channel is then either further 
channelized into 32 narrowband 64-kbps channels (28 of 
which are high quality) or passed directly on to the multirate 
demodulator as a 2.048-MHz channel. The modulation for- 
mat used is differentially encoded (offset quaternary phase- 
shift keyed, or OQPSK), and the overall bandwidth effi- 
ciency of this system is 1.42 bps/Hz. The multirate demodu- 
lator can demodulate either one 2.084-MHz channel or thirty- 
two 64-kbps channels. This demodulator is designed as a 
continuous demodulator (fig. 11). 

The University of Toledo is in the fourth year of a grant 
(NAG3-799) to develop a programmable architecture for 
multicarrier demodulation that will be based on parallel and 
pipeline digital design techniques for increased throughput. 


The hardware architecture and designs have been optimized 
for variable channel rates and variable numbers of channels. 
A POC model to demonstrate small-scale operation is under 
development. 

MF-TDMA Demodulator 

Once the demultiplexing function has been completed, the 
individual channels have to be demodulated. There will be 
one active demodulator per frequency channel. Currently, dif- 
ferential QPSK is being considered for this approach. In or- 
der to simplify the demodulator hardware by eliminating the 
phase tracking problem, differential QPSK has been selected 
over coherent QPSK. The MF-TDMA concept requires all 
transmissions to be bit synchronous at the satellite. There- 
fore, network synchronization is a major concern. Studies 
have indicated that uplink transmission will have to be within 
l/40th of a bit time in order to maintain quality transmission 
(ref. 21). Earth terminals will be notified of timing offsets. 
Timing offset will be tracked as part of the demodulation 
system. 
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The MF-TDMA demodulator is a critical component that 
has yet to be demonstrated in hardware. The European Space 
Agency currently has a program to develop such a device 
(refs. 22 to 24). 

Shared Decoder 

The decoder subsystem decodes each subpacket on a 
subpacket-by-subpacket basis. There will be one decoder 
subsystem per demodulator. The decoder subsystem will con- 
sist of either two separate block decoders (one for header 
subpacket decoding and one for information subpacket 
decoding) or a reconfigurable block decoder. The MF- 
TDMA environment simplifies the decoder subsystem 
because it forces packet and subpacket alignment. All header 
subpackets are contained in the First subframe with all infor- 
mation subpackets in the remaining subframes. This requires 
a reconfiguration or switch between header and information 
block decoders only on the subframe boundary. 

A quality of service throughout the satellite network of at 
least 10 -7 is desired. The information subpacket code rate 
will be selected to meet this criterion. We expect that the 
extra bits available to the header subpacket will allow for suf- 
ficient header coding to meet the overall network bit error 
rate of 10“ 7 . A formal analysis needs to be completed in this 
area — particularly with regard to the effect of misrouted 
packets and multicasting, 

Information-Switching Processor 

The information-switching processor is one of the major 
systems within the mesh VSAT onboard-processing satellite. 
It consists of the baseband switching and routing elements 
and the satellite control and monitor subsystem — particularly 
those portions that monitor and control the downlink burst 
buffers and dwell times. 

Switching and Routing Elements 

A major consideration in designing the switch is conten- 
tion. Contention occurs when two or more inputs attempt to 
route to the same output simultaneously. This is extremely 
difficult to avoid. Therefore, the switch must be designed to 
accommodate such occurrences. Studies have indicated that 
both contention-based and contention-free switch architec- 
tures can be utilized (refs. 13 and 25). However, contention- 
based switch architectures require excessive buffering and, in 
some instances, packet reordering. Also, contention-based 
switches have a greater tendency toward dropping packets 
than does a contention-free switch. Contention-free switches 
having a throughput capacity of approximately 1.5 Gbps can 
be implemented with today's technology. Because our switch 
throughput is in the 500- to 600-Mbps range and one of our 
requirements is maintaining a negligible packet loss rate, 
only contention-free switch architectures are being consid- 


ered. Two types of contention-free switches have been iden- 
tified: shared memory and shared bus. 

Shared-Memory Packet Switch 

The shared-memory packet switch utilizes a single data 
memory for storing and switching packets onboard the satel- 
lite. Incoming packet data are written into the data memory at 
the first available unused memory location. Temporal and 
spatial switching of the packet data to the correct destination 
beam and dwell is achieved by controlling the order in which 
data are read from the memory. Data memory reads are con- 
trolled by the beam address memories and the control 
memory. Because this data memory is shared by all of the 
output (downlink) ports of the satellite, the shared-memory 
approach more efficiently uses the memory resources than 
other switching architectures. The shared-memory architec- 
ture is nonblocking and free of output contention. Congestion 
control must be considered with this approach to avoid out- 
put buffer overflows. 

The block diagram of the shared-memory packet-switch 
architecture is shown in figure 12. It is assumed that the 
packets arriving at the 256 input ports to the ISP switch are 
fully assembled packets which are synchronized so that the 
headers are aligned. The data packets arriving at the 256 
input ports of the switch are stored into first-in, first-out 
memories (FIFO’s), which provide rate buffering and stag- 
gering of the input data to allow data from all 256 inputs to 
be multiplexed onto a single TDM bus. The data rate into 
each FIFO is equal to the uplink burst rate of 2.048 Mbps; the 
FIFO output data rate, 524.288 Mbps, is the aggregate rate of 
all the input ports combined (256 x 2.048 Mbps), Data are 
read out of each FIFO in fixed-size blocks. The minimum 
block size is one packet length and the size of the FIFO is 
directly proportional to the chosen block length. Each of the 
256 FIFO’s is accessed one at a time in order from FIFO 
number 1 to FIFO number 256. The 256 output FIFO data 
buses are then combined into a single TDM bus by using a 
256-to-l multiplexer. 

As the packets are routed on the TDM bus from the multi- 
plexer to the data memory, the headers are tapped off and 
sent to the header decoder. The headers indicate the destina- 
tion downlink beam and dwell for point-to-point communica- 
tions traffic. They also signify multiple destination beams, 
dwells, or both for multicasting and broadcasting. The header 
decoder determines the packet destinations and creates the 
proper addresses and enables so that the control memory 
pointers can be written into the address memories. 

When a new packet arrives at the input to the data 
memory, an available memory address is fetched from the 
address pool FIFO. This data memory address is written into 
the next sequential address in the control memory and that 
control memory address is written into the address memory 
location determined by the header decoder. An address 
memory is allocated for each of the eight downlink beams, 
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Figure 12. — Shared memory. 


and each memory is divided into a maximum of eight dwell 
locations of variable lengths. The locations of the dwells 
within the downlink frame and the length of the dwells are 
controlled by network control according to the current satel- 
lite traffic situation. The remainder of the packet is then 
stored in the sequential data memory address locations fol- 
lowing the initial data memory address. 

The address pool FIFO contains all currently unused data 
memory addresses. At startup the address pool FIFO contains 
all the data memory addresses starting with address 0 and 
located every 1024 bits (total packet length) thereafter. If the 
TDM bus is chosen to be 32 bits wide, the available data 
memory addresses will be spaced 32 address locations apart 
(1024/32 = 32). When a data memory address is used, it is 
removed from the address pool FIFO. 

The data memory is designed in a dual-port configuration 
so that data memory reads and writes can occur simulta- 
neously. At startup a full frame of data is written into the data 
memory before any data are read out and routed to the down- 
link ports. Subsequently, frame M will be written into the 
data memory while frame M-l is read out of the data 
memory. As each packet exits the data memory, the address 
location that contains the packet becomes available and is 
written into the address pool buffer. The data memory will be 
sized slightly larger than a full frame of data so that there will 
always be available addresses in the address pool buffer. 

In order to read the downlink data out of the data memory, 
first the address memories are sequentially accessed. For the 
first read the address memory corresponding to the first 
packet in downlink beam 1 and dwell 1 is read. The address 
memory data contents point to a control memory address. 
This control memory address contains the data memory 
address that holds the data packet destined for downlink 
beam 1 and dwell 1. The address memories are then 


rotated through sequentially until one packet is read from the 
data memory for each sequential downlink beam. Then 
address memory 1 is accessed again for the second packet for 
downlink beam 1, dwell 1. This process continues until all 
data for that frame have been read. Both the address memo- 
ries and the control memory are arranged in a ping-pong con- 
figuration so that one memory is written to while the other is 
read (and visa versa). The write and read functions are 
switched on frame boundaries. 

Multicasting and broadcasting services are readily sup- 
ported by the shared-memory switch architecture. When a 
multicasting or broadcasting packet is received by the switch, 
only one copy of the packet must be stored in the data 
memory. The header decoder maps the multicasting (or 
broadcasting) header information into multiple beam address 
memory locations corresponding to the multiple destinations 
of the packet. At each of these multiple beam address 
memory locations a single identical control memory address 
is written. This control memory address points to the location 
in the data memory where the multicast packet is stored. Spe- 
cial control must be provided to avoid writing the data 
memory address of the multicast packet into the address pool 
FIFO before the last copy of the packet is transmitted to the des- 
tination beams. One technique for handling this situation is to 
include a count field in the data memory with each packet. Each 
time a packet is used, the count field is decremented. When the 
count field is 1, the packet is used for the last time and the data 
memory address is written into the address pool FIFO. 

Modifications to the shared-memory architecture are being 
examined to further improve memory utilization. The modi- 
fications under consideration include eliminating the use of 
the ping-pong memories, using in-place data memory design, 
and using subpacket transmissions. In using the first 
approach the size of the beam address memories and the con- 
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trol memories is halved by using single memories rather than 
ping-pong memories (ref. 25). Doing this would complicate 
the switch timing and control circuits, and the memory sav- 
ing is minor relative to the size of the data memory. The sec- 
ond approach, adopting an in-place switch concept for the 
data memory implementation, would require an incoming 
packet to be written to the address location of the current out- 
going packet. As in the first approach this technique would 
require more sophisticated timing and control mechanisms. 
Memory saving would include eliminating the address pool 
FIFO and slightly downsizing the data memory to hold 
exactly one frame of data. Additionally, the control memory 
could become a simple look-up table with unchanging con- 
tents or could be eliminated altogether. Again, only a small 
memory saving is realized with this approach. The third 
approach segments the incoming packets into smaller blocks 
called subpackets, with the block size as small as the header 
length. Using subpackets could result in a significant 
decrease in the size of data memory. In this approach only 
subpackets are stored in the data memory, rather than full 
packets. The packet header reaches the switch first, sets up 
the beam address memories and the control memory, and is 
stored in the beam memory. On the next cycle of the data 
memory the headers are forwarded to their destination 
beams, and the next subpackets are received and stored in the 
data memory. The beam address memories and the control 
memories stay the same until the entire packet has been 
received and forwarded to its destination and a new header 
subpacket is received. 

Shared-Bus Packet Switch 

A shared-bus architecture is similar to the shared-memory 
architecture except that instead of having a common output 
memory, the output memories are distributed — one memory 
per beam or one memory per dwell. Data are transmitted 
from input ports to output ports over a shared bus with the 
bus operating at the sum of the incoming traffic rates. For 
this system the bus would have to operate at more than 
524.288 Mbps. Multicasting and broadcasting are readily 
accommodated with this architecture. 

The shared bus operates in the following manner: Packets 
are stored at the input ports corresponding to each wideband 
input channel. Each packet has a header and data associated 
with it. The packets are multiplexed onto a time-shared bus at 
a high rate. Each destination reads the address and deter- 
mines whether or not the packet is for that particular destina- 
tion. If so, the packet is forwarded to the downlink burst 
memory. 

The shared-bus architecture may be implemented as an 
electrical bus or a fiber-optic ring (figs. 13 and 14). The elec- 
trical bus has noise, interconnect, and loading problems that 
must be overcome. Both implementations require the 
address-processing electronics to operate at an extremely 
high speed in order to process the headers and then forward 



Figure 13. — Electronically implemented shared bus. 


the data. In addition, the shared-bus architecture works best 
with full packets that include header and information in one 
packet. This forces complete packets to be assembled and 
buffered onboard the satellite before switching. The memory 
required to accommodate this is considered excessive. 

A modification of the shared-bus architecture is being con- 
sidered that uses subpackets. Similar in operation to the TDM 
downlink, the subpacket would be used to set up the routing. 
Once the routing is determined, each receiver will know 
where, in each subframe, the appropriate information 
subpackets reside — almost identical in operation to the mes- 
sage assembler in the Earth terminal. This requires that all 
information subpackets are transmitted and routed throughout 
the satellite network in the same order as the header 
subpackets. This does not appear to be a problem in an 
MF-TDMA environment. 

Codec 

The encoder is required to provide coding gain on the 
downlink. Because the information to be transmitted is in 
subpackets, a block encoder capable of operating at 
160 Mbps will be used. Encoding is simpler and requires less 
power than decoding, making an onboard 160-Mbps block 
encoder very practical to implement. A corresponding 
decoder is required at the Earth terminal. Because power is 
not a significant problem on the ground, implementation of 
the more complex decoder is reasonable. Block decoders that 
handle these rates are available as commercial products. 

Modulator 

A burst modulator capable of a bandwidth-efficient modu- 
lation scheme is required. A continuous phase-modulation 
format is desired in order to run the satellite’s high-power 
amplifiers at saturation, thus improving the downlink effi- 
ciency. NASA Lewis has as an ongoing program in modula- 
tion and coding directed at such requirements. Among these 
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Figure 1 4. — Optically implemented shared bus. 


are two completed contracts for burst modems for satellite- 
to-ground applications: a 16-continuous-phase, frequency- 
shift-keyed (CPFSK), 200-Mbps modem; and an 8-phase- 
shift-keyed (8-PSK), 160-Mbps modem (refs. 26 and 27). 
Additional work is being performed by COMSAT Laborato- 
ries under contract NAS3-319317 for a programmable digi- 
tal modem capable of binary, QPSK, 8-PSK, and 16 quadra- 
ture amplitude modulation with as many as 300 Mbps of data 
throughput (ref. 28). 

Satellite Control and Monitor 

The satellite control and monitor (SCM) system is respon- 
sible for allocation of the space and ground resources and for 
real-time health monitoring and fault recovery of the onboard 
communications systems in addition to performing those net- 
working functions required onboard the satellite. The SCM 
will monitor the downlink burst buffers’ capacity, forward 
the burst buffer status to the Earth terminals by downlink 
orderwires, and vary the length of the downlink dwells to 
accommodate changing traffic patterns. In addition, the SCM 
will control the burst transmissions and the hopping-beam 
antenna system. Ideally, traffic allocation and routing func- 
tions will be placed onboard to shorten call setup and discon- 
nect times. However, processing requirements, reliability 
issues, difficulty in modifying software, and the inability to 
update hardware make this practice inadvisable in the near 
term. 


Network Control 

The network control resides on the ground. It is respon- 
sible for allocation of all network resources and handles 
requests for connection, disconnection, and bandwidth. Net- 
work control is also responsible for bringing new terminals 
into the system, monitoring traffic patterns, and updating the 
burst time plans (satellite beam dwell allocations). By keep- 
ing these functions on the ground, hardware and software can 
easily be updated and greater network flexibility is achieved. 
Also, reliability and fault tolerance are easily handled on the 
ground. 

Concluding Remarks 

Any onboard processing system requires fault-tolerant 
implementation. With size, weight, and power at a premium, 
traditional fault-tolerant methods, such as simple two-for-one 
redundancy of components and systems or majority voting, 
will not suffice. NASA Lewis plans to address these issues in 
all aspects of the satellite design and is pursuing innovative 
fault-tolerant approaches that optimize redundancy require- 
ments. Presently, the issue of fault tolerance in the digital 
multichannel demultiplexer is being addressed through a 
grant with the University of California, Davis (NAG3-1 166). 
A simulation of the proposed protection scheme for a 
polyphase multichannel demultiplexer using C language 
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modules coupled with MatLab operations has been con- 
structed. An approach that protects the operations of the ana- 
log- to-digital converters at the front end is included in this 
simulation, A new protection scheme for a practically imple- 
mented fast Fourier transform realization that employs only a 
few processing elements is being considered. Techniques are 
being developed for scheduling butterfly operations on proc- 
essors while still preserving the error-detecting capabilities. 


Status and Future Directions 

NASA plans to develop a proof-of-concept information- 
switching processor (ISP) and desires to develop a proof-of- 
concept multiple-frequency-time-division-multiple-access 
(MF-TDMA) modem and a reconfigurable block codec. The 
ISP will be constructed in-house at the NASA Lewis 
Research Center and may be supplemented by advanced 
fault-tolerant components developed under contracts if criti- 
cal, stand-alone components are identified. The ISP will be 
demonstrated in a satellite network simulation. The switching 
hardware will be simulated by using traffic patterns gener- 
ated by means of network simulation software. The downlink 
dwell buffers of the ISP will be monitored for congestion. 
The dwell buffer status will be fed back to the network simu- 
lation model, which will then institute various congestion 
control algorithms that, in turn, will modify the simulated 
user traffic patterns. This will demonstrate both the switching 
and flow control that are considered two of the more critical 
elements of a destination-directed, packet-switched commu- 
nications satellite network. 

The MF-TDMA modem is a critical element in the 
MF-TDMA/time-division-multiplexed (TDM) architecture 
that has yet to be demonstrated in hardware. NASA has great 
interest in seeing such an element developed and fully tested. 
Testing would require multiple modems and the ability to 
either simulate uplink delay or utilize an actual satellite link 
in order to fully test the bit-synchronous timing aspects 
required for MF-TDMA. 

A reconfigurable block decoder subsystem would be nec- 
essary for an experimental flight demonstration but is not 
considered a critical element relative to the MF-TDMA 
modem and the ISP. This system may be developed at a later 
date. 


Appendix — Network Timing Analysis 

Uplink Packet Analysis 

Because maintaining an uplink packet efficiency of 
approximately 85 percent or greater is desired, we have cho- 
sen each message packet to consist of 16 subpackets: 
1 header subpacket and 15 information subpackets. This 
appendix gives an analytical explanation of these choices. 

Let B uh and By f be the number of uncoded header bits 
and information bits per subpacket. Let B CH and B CI be the 
number of coded header and information bits per subpacket. 
We need to add forward error correction to the header and 
information bits and desire to have more robust coding on the 
header bits. Let CR H and CRj represent the header and infor- 
mation subpacket code rates. Then, the number of transmitted 
bits per header and information subpacket, B CH and B CF is 
given by 


S CH 
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( 2 ) 


In order to simply the hardware, we force 


b ch ~ B a 


(3) 


This gives 


CRh=^ (4) 

We define the packet efficiency rf F to be the number of infor- 
mation bits per packet divided by the total number of trans- 
mitted bits, where N { is the total number of information 
subpackets per packet: 
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TABLE III. - PACKET EFFICIENCY 
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mum amount of time a dwell will be illuminated in one 
frame. 


t tdm = kTp 

( 9 ) 

k = N ° M 

N P 

( 10 ) 


Here, k> the minimum total illumination time that any dwell 
receives during a frame, may be specified as a fraction of a 
frame or as the minimum number of packets that the smallest 
dwell will be required to service And Np is the total 
number of packets per frame and is given by 


Table III shows the packet efficiency for various numbers 
of information subpackets per packet. Note that the packet 
efficiency depends not on the size of the packets but on the 
number of information subpackets and the information 
subpacket code rate. 

Uplink MF-TDMA Frame Analysis 

Each 40-MHz uplink beam has 32 wideband channels 
separated in frequency and transmitting at 2.048 Mbps 
(uncoded transmission rate). Each wideband channel is 
further separated into 32 timeslots with each timeslot corre- 
sponding to a narrowband channel with an uncoded informa- 
tion rate Ryj of 64 kbps. The narrowband packet transmis- 
sion rate Rp is given by the coded narrowband transmission 
rate divided by the number of coded bits per packet, 

R P R V< ICR I (7) 

NjB a +B C h 


n p = ^ t f ( 11 ) 

Bp 

where the downlink burst rate, is defined as the rate at 
which uncoded packets are transmitted exclusive of pre- 
ambles and forward error correction coding and Bp is defined 
as the total number of bits per packet. The minimum dwell 
time is given by 


t dm - 


t tdm 

N ,+ 1 


( 12 ) 


For a downlink burst rate of 160 Mbps, a 32-msec frame, 
and a packet length of 2048 bits, 2500 packets are transmitted 
every frame. We will assume that a beam’s dwell location 
should service at least 100 packets (k = 0.04). Therefore, the 
minimum dwell time will be 80 psec (1/16 of the total dwell 
time in a frame), which is a reasonable amount of time for 
updating the beam-forming network. 


From equations (1) to (3) and (7) 

R = Rul 
P (*,+!)% 


( 8 ) 


For 64 kbps, 128 bits per subpacket, and 16 subpackets per 
packet the packet transmission rate is 31.25 packets per sec- 
ond. Assuming we want at least one full packet per frame 
gives us a 32-msec uplink frame, a 2-msec subframe, and a 
62.5-psec timeslot. 

Downlink TDM Frame Analysis 

In order to ease network timing, we desire that the uplink 
and downlink frames should be equal. Therefore, the down- 
link frame time T F is 32 msec. Now, we wish to determine 
the minimum dwell time t dm. the inverse of the minimum 
beam update rate. First, we define T tdm as the total mini- 
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